Individuals and businesses often seek ways to prevent the unintended loss of valuable data. For example, an entity may back up data by replicating the same from a primary site to a secondary site. In many cases, the copy of data at the secondary site is continuously updated to mirror the primary site.
In some cases, computing systems at the primary and/or secondary site may belong to a data cluster. Clustered computing systems may allow applications to continue on another node when a node within a particular cluster fails.
In general, dependent writes performed at the primary site must be performed in the same order at the secondary site. In contrast, independent, or concurrent, writes may be performed in parallel. Because of this, replication systems often use replication logs to track the order of such writes. These systems may also distinguish between dependent and concurrent writes, but may err on the side of designating a write as dependent. Unfortunately, such systems may be required to update the replication log for each and every concurrent write, which may introduce a significant performance overhead. These systems may also designate writes as concurrent or dependent based on write completion time, which may be imprecise. For example, additional dependent writes may occur between the time that write completion is reported to an application and the time that write completion is reported to a node that manages the replication log.